Mechanics of caching
The SDO is the data-managing interface between the AppServer and your client application. Enabling a cache is like placing a bucket between the AppServer and the SDO, as shown in the following figure:
The result set of the SDO’s query is stored as a temp-table in the cache, and any reference to that SDO forces the SDO to check the cache, find the temp-table, and retrieve the data. When the necessary data is not available or has expired, the cache will get what it needs from the AppServer.
The framework accomplishes this caching not by implementing a true physical cache in memory, but by using the seamless versatility of temp-tables. Since dynamic temp-tables received as a parameter are scoped to the session by default, they are completely capable of being used as a cache. Temp-tables are active, so SDOs can operate directly on cached data. There is no need to duplicate data and no need to synchronize updates with the cache. The cached data can be navigated and browsed independently by multiple instances by utilizing the 4GL’s ability to define separate buffers on a temp-table.
For SDOs that are defined with statically defined temp-tables, they will not be able to store or use data from the cache as efficiently as dynamic SDOs. A static temp-table is scoped to the procedure that defines it, so it is necessary to either keep the defining procedure running or keep a dynamic copy of the temp-table in the cache. In the cases where an SDO with a static temp-table definition is running on the client session, the static data will be copied to and from the cache.